可能会|也就是_TCP：当初取代NCP，如今害怕被取代

篇首语：本文由编程笔记#小编为大家整理，主要介绍了TCP：当初取代NCP，如今害怕被取代相关的知识，希望对你有一定的参考价值。

我叫TCP&＃xff08;Transmission Control Protocol&＃xff09;也叫传输控制协议。不觉回忆1983年&＃xff0c;亲手将NCP协议淘汰&＃xff0c;取而代之的是我&＃xff0c;成了火遍大江南北的网络红人之一。

现如今&＃xff0c;我感受到前所未有的恐惧&＃xff0c;因为我一生的敌人UDP正在赶超我&＃xff0c;甚至将我取而代之。

我的生平

我在1974年被我的父亲罗伯特·卡恩和温特·瑟夫设计出来&＃xff0c;和我一同出生的也是如今的网络红人IP&＃xff0c;我们是一对亲密无间的组合——TCP/IP&＃xff0c;我在网络七层模型里的4层——传输层&＃xff0c;而IP兄弟是负责网络层。

我的作用就是负责传输数据&＃xff0c;并代替NCP协议的工作&＃xff0c;因为它不能跨系统通讯&＃xff0c;怎么说呢&＃xff0c;就是如果大家用了Windos操作系统&＃xff0c;就没法和MacOs操作系统进行通讯&＃xff0c;这非常不利于互联网的发展&＃xff0c;我很抱歉NCP一时被抛弃&＃xff0c;但是我们依然坚信“物竞天择&＃xff0c;适者生存”的道理。

起初出生时&＃xff0c;我们并没有大家想象的那么容易。刚出生时的我是非常简陋的&＃xff0c;我的IP兄弟负责每个机器分配一个IP地址标识。IP兄弟像是为我铺好了康庄大道&＃xff0c;而我只需要将数据包运输到目的地。而我们也比较争气&＃xff0c;我的父亲卡恩和瑟夫为我做了一个实验&＃xff0c;将一个数据包从一端发出&＃xff0c;经过10万千米的旅程后到达服务端。这个传输过程&＃xff0c;数据包没有丢失一个字节&＃xff01;

但是&＃xff0c;我们的命运和其他伙伴一样&＃xff0c;新技术或新标准起初总是会受到强烈的抵制。特别是标准化组织ISO推出了著名的ISO七层模型&＃xff0c;那时我又被强烈的鄙视了一番。

不得不说&＃xff0c;父爱是伟大的&＃xff0c;他们经过4年时间的不断对我们改进&＃xff0c;为我和IP兄弟完成了基础框架的搭建。

尽管阻碍重重&＃xff0c;我的父亲卡恩和瑟夫进行了长期的斗争。

终于&＃xff0c;在1983年被美国国防部高级研究计划局决定淘汰NCP协议&＃xff0c;我和IP兄弟取而代之。

这个过程&＃xff0c;整整过去了10年的时间。我和我的亲兄弟IP终于站稳了脚跟&＃xff0c;分别负责七层模型里的传输层&＃xff0c;网络层。

现如今&＃xff0c;接触计算机的朋友们对我一定不陌生。我在网络中扮演着重要角色&＃xff0c;你们发送的信息基本上都是我在负责的&＃xff0c;每时每刻都在处理成千上万用户的信息&＃xff0c;还要安全且无误的传输到指定的地方。

这时候你可能反应过来了&＃xff0c;你用手机&＃xff0c;电脑等设备对你恋人或者亲人说的话&＃xff0c;语音&＃xff0c;视频都是我负责帮你们成功抵达&＃xff0c;而且是准确无误&＃xff0c;因为至今正常情况下我没有收到你们错误信息的抱怨。

我可以自信地说是印度洋和太平洋之间重要枢纽——马六甲海峡。

当然我的亲兄弟IP也是功不可没&＃xff0c;它为我连通了各个设备搭建好了桥梁&＃xff0c;那么我根据IP我就能找到准确的人给他发送。而且还划分了网段&＃xff0c;这样你在浙江给在北京的爱人发信息&＃xff0c;那我一定是往北走&＃xff0c;而不是往西&＃xff0c;或者往南走。

你可能会好奇&＃xff0c;我是怎么做到每时每刻处理成千上万的信息安全且无误地传输到目的地。这得归因于我父亲对我的设计了&＃xff0c;他们致力于让我成为一个安全且靠谱的“运输卡车”。

三次握手机制

第一次握手&＃xff0c;做了什么&＃xff1f;

这第一个安全的设计&＃xff0c;就是连接机制&＃xff0c;为了确保能够建立正确的连接&＃xff0c;大部分情况下我需要三次连接才能建立安全可靠的传输通道。也就是你们常说的“三次握手”连接。

首先客户端要和服务端建立TCP连接&＃xff0c;也就是建立通讯管道。会先发一个SYN报文&＃xff0c;这是一个请求同步连接的报文&＃xff0c;发送之后此时的客户端会进入到SYN-SENT状态。

如果客户端迟迟收不到服务端的SYN-ACK&＃xff08;同步应答&＃xff09;报文&＃xff0c;就会触发超时重传机制&＃xff0c;重新把刚才的SYN报文重新发送&＃xff0c;而且重传的SYN报文的序列号都是一样的。

你可能会好奇客户端没有收到应答之后&＃xff0c;多久才会触发重传且需要重传几遍才肯罢手。

不同版本的操作系统可能超时时间不同&＃xff0c;有的 1 秒的&＃xff0c;也有 3 秒的&＃xff0c;这个超时时间是写死在内核里的&＃xff0c;如果想要更改则需要重新编译内核&＃xff0c;比较麻烦。

在 Linux 里&＃xff0c;客户端的 SYN 报文最大重传次数由 tcp_syn_retries 内核参数控制&＃xff0c;这个参数是可以自定义的&＃xff0c;默认值一般是 5&＃xff0c;所以这个可以是由操作系统来设定的。

假如我们设置初始超时重传1秒&＃xff0c;最大重传次数为5次。那么客户端第一次超时重传是在1秒&＃xff0c;第二次超时重传是在2秒&＃xff0c;第三次超时重传是在4秒&＃xff0c;第四次超时重传是在8秒&＃xff0c;第五次超时重传是在16秒。我们可以看到规律&＃xff0c;每次超时时间是上一次的2倍。

当到了第五次重传时&＃xff0c;将继续等待32秒之后服务端还是没有响应ACK&＃xff0c;客户端将不再发送SYN包&＃xff0c;然后断开TCP连接。

▲图/ 第一次握手超时重传机制

第二次握手&＃xff0c;做了什么&＃xff1f;

第二次握手&＃xff0c;也就是客户端发送的SYN报文&＃xff0c;如果服务端收到了就会返回一个SYN-ACK报文给客户端&＃xff0c;并且服务端进入SYN_RCVD&＃xff08;同步已接收&＃xff09;状态。

此时的SYN-ACK报文做了两件事&＃xff0c;一件是对第一次握手时做个回应确认报文已经收到。另一个是服务器既然收到了便会发起建立TCP通信管道的连接的报文&＃xff0c;这个地方是一个发送请求时间&＃xff0c;如果没有得到ACK回应则会触发超时重传机制。

此时&＃xff0c;如果服务端的SYN_ACK报文发送了之后&＃xff0c;如果丢失或者某种原因导致客户端没有收到&＃xff0c;只要客户端没有接收到就会触发超时重传机制&＃xff08;会有计时器&＃xff0c;超过时间没接收到就重传&＃xff09;&＃xff0c;重传SYN报文。

当然为了确保稳定&＃xff0c;不仅客户端会有重传机制&＃xff0c;服务器也会有超时重传机制&＃xff0c;重发SYN-ACK报文。

在 Linux 下&＃xff0c;SYN-ACK 报文的最大重传次数由 tcp_synack_retries内核参数决定&＃xff0c;默认值是 5。

▲图/ 第二次握手超时重传机制

第三次握手&＃xff0c;做了什么&＃xff1f;

这个时候&＃xff0c;客户端收到服务端的ACK应答报文并发起了TCP建立连接请求&＃xff0c;此时客户端收到并对TCP建立连接得请求发送一个ACK应答报文&＃xff0c;并且客户端进入ESTABLISH的建立连接状态。

我们可以看到此时的第三次握手是基于第二次握手服务端发来的SYN的确认报文&＃xff0c;如果客户端没有收到&＃xff0c;那么服务端此时会触发超时重传机制&＃xff0c;进行重发相同的ACK报文。

▲图/ 第三次握手超时重传机制

由此&＃xff0c;我们也可以总结出结论&＃xff0c;ACK应答报文并不会有重传机制&＃xff0c;当ACK丢失了&＃xff0c;由对方发来的SYN报文进行重传。

以上就是我的建立连接机制了。你们可能会看起来比较麻烦&＃xff0c;特别是当今世界如果聊天出现了三次握手的情况&＃xff0c;你们一定是不耐烦的。然而&＃xff0c;我这是牺牲了一定的速度来确保安全以及稳定的作用&＃xff0c;我想人们更多情况下都是求安全且稳定的。

四次挥手机制

我虽然在一定程度上具有传统且保守的态度&＃xff0c;但是我一定是力争求稳&＃xff0c;且有始有终&＃xff0c;是你们靠谱的伙伴。所以&＃xff0c;在传输结束时&＃xff0c;我也有一套安全稳定的断联机制。就是你们俗称的“四次挥手”。

第一次挥手&＃xff0c;做了什么&＃xff1f;

第一次挥手&＃xff0c;当客户端所有的消息都发送完之后&＃xff0c;会主动调用close函数&＃xff0c;然后向服务器发送FIN&＃xff08;完成&＃xff09;报文&＃xff0c;试图和服务器断开连接&＃xff0c;并且状态进入到FIN_WAIT_1状态。

客户端不管何种情况&＃xff0c;只要没有收到ACK报文&＃xff0c;就会触发超时重传机制&＃xff0c;重传FIN报文&＃xff0c;重传次数也是由操作系统 tcp_orphan_retries 参数设置。

▲图/ 第一次挥手超时重传机制

超时重传到达 tcp_orphan_retries 的次数之后&＃xff0c;就不再发送FIN报文&＃xff0c;则会等待上一段时间的2倍之后还是没有收到&＃xff0c;则直接进入close状态。

第二次挥手&＃xff0c;做了什么&＃xff1f;

第二次挥手&＃xff0c;服务端收到客户端的第一次挥手之后会回传一个ACK确认报文&＃xff0c;此时服务端的状态进入到CLOSE_AWAIT状态。

由于ACK报文是没有重传机制的&＃xff0c;所以一旦服务端没有把ACK回传给客户端且接收到&＃xff0c;则由客户端发送方来触发超时重传机制。这也是一问一答式的&＃xff0c;必须有问有答才算一回合结束。

▲图/ 第二次挥手超时重传机制

客户端收到ACK报文&＃xff0c;则状态由FIN_WAIT_1变为FIN_WAIT_2的状态。这个状态需要等待服务端发送第三次挥手&＃xff0c;也就是服务端的FIN报文。

这里&＃xff0c;客户端收到ACK进入到FIN_WAIT_2状态之后&＃xff0c;调用close关闭函数&＃xff0c;之后便无法再发送和接收数据&＃xff0c;所以这个FIN_WAIT_2状态也不会持续很长&＃xff0c;而 tcp_fin_timeout 控制了这个状态下连接的持续时长&＃xff0c;默认值是 60 秒。

▲图/ close函数关闭机制

意味着如果在60秒后还没有收到FIN报文&＃xff0c;客户端的连接就会直接关闭。

但是如果客户端&＃xff08;主动方&＃xff09;关闭使用shutdown函数代替close函数关闭连接时&＃xff0c;指定了只关闭发送方&＃xff0c;而接收方并没有关闭&＃xff0c;那么主动关闭方还是可以接收数据的。

服务端&＃xff08;接收方&＃xff09;还在处于接收状态就无法发送FIN报文&＃xff0c;那么客户端&＃xff08;主动方&＃xff09;就会一直处于FIN_WAIT_2状态&＃xff0c;你可能会想tcp_fin_timeout这个时间倒计时可以主动关闭状态。很遗憾&＃xff0c;tcp_fin_timeout这个参数只对close函数有用&＃xff0c;对shutdown函数无效&＃xff0c;并会处于一直等待中&＃xff0c;没有杀死这个线程甚至可能死等中。这是一个不到万不得已的下策。

▲图/ shutdown函数关闭机制

第三次挥手&＃xff0c;做了什么&＃xff1f;

到了这里&＃xff0c;进入到第三次挥手。在上一轮服务端进入CLOSE_WAIT状态后&＃xff0c;进程主动调用close函数进入到内核&＃xff0c;内核会发送一个FIN报文&＃xff0c;同时进入LAST_ACK状态&＃xff0c;等待客户端返回ACK来确认连接关闭。

▲图/ 第三次挥手超时重传机制

这里&＃xff0c;如果迟迟收不到客户端返回的ACK报文&＃xff0c;则依然会触发重传机制&＃xff0c;重发次数仍然由tcp_orphan_retries 参数控制。

第四次挥手&＃xff0c;做了什么&＃xff1f;

服务端发送了FIN报文之后&＃xff0c;就进入到第四次挥手了。当客户端收到服务端的第三次挥手的FIN报文之后&＃xff0c;就会回传一个ACK报文&＃xff0c;也就是第四次挥手&＃xff0c;并且进入到TIME_WAIT 状态。

TIME_WAIT状态根据操作系统的不同&＃xff0c;一般Linux系统是持续2MSL&＃xff08;2倍的最大生存时间&＃xff09;进入关闭状态。

▲图/ 第四次挥手超时重传机制

服务端若没有收到客户端发来的ACK报文&＃xff0c;则依然处于LAST_ACK状态。超时未接收到则客户端会触发超时重传FIN报文&＃xff0c;重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制。

时代的眼泪

你看&＃xff0c;这是我有始有终的机制&＃xff0c;对于我来说&＃xff0c;每一步都不是多余&＃xff0c;都是为了双方能够建立安全稳定的通道&＃xff0c;不会在错重复杂的通讯管道中将数据错误的传达。

当然&＃xff0c;这些是我在连接和断开方向上的主要特点。我的主要功能不仅这些&＃xff0c; 重传、滑动窗口、流量控制、拥塞控制都是我的一套完整的高可用体系。

在我和应用层HTTP组合已经有四十年左右&＃xff0c;在此期间我可以是撑起整个互联网的元老之一&＃xff0c;毫不夸张的自诩为互联网的血脉。但是也难挡时代带来的风霜&＃xff0c;我有一个死对手UDP&＃xff0c;这个将是我永远过不去的坎&＃xff0c;以前我从没觉得它能够赶超我甚至替代我&＃xff0c;它的好处就是快&＃xff0c;靠不靠谱我不说。

但是随着时代的发展&＃xff0c;人们对于速度的要求越来越高&＃xff0c;人们不断地改良网络模型&＃xff0c;我的兄弟也在升级&＃xff0c;已经有了IPv6&＃xff0c;而与我患难与共的HTTP&＃xff0c;则是不断的从1.0优化到了3.0&＃xff0c;这个版本的出现彻底的让我感到emo&＃xff0c;因为http3.0版本已经使用我的死对头来替换了我&＃xff0c;他们将UDP的速度发挥起来&＃xff0c;并且对于安全连接和数据校验相关做了很好的控制。

这也是我为什么要开始emo和吐槽了。

&＃x1f447; 更多有趣内容&＃xff0c;请多关注&＃xff01;&＃x1f447;